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1  Introduction 

The  confidentiality  of  information  in  multi-level  secure  systems  is  maintained  by 
sanitising  requests  for  information  according  to  the  requester’ s  clearance.  However, 
information  can  flow  indirectly  through  subtle  modulations  of  shared  resources  —  so- 
called  "signalling  channels".  These  channels  can  be  avoided  in  specifying  secure 
systems,  but  as  a  system  specification  is  progressively  refined  in  the  design  process, 
extraneous  behaviours  can  easily  be  introduced,  opening  up  more  and  more  signalling 
channels.  The  process  of  constructing  a  system  which  is  free  from  signalling 
channels  is  therefore  two-fold:  firstly,  show  that  the  system  specification  is  free  from 
threatening  signalling  channels,  by  demonstrating  its  correspondence  to  a  security 
policy  model;  secondly,  prove  that  successive  design  specifications  do  not  introduce 
additional  signalling  channels,  i  e.  they  are  ’secure  refinements’  of  the  system 
specification. 

This  paper  identifies  "behavioural  equivalence"  as  a  mathematical  notion  of  secure 
refinement  for  SMiTE-based  systems,  and  proposes  suitable  proof  obligations  It  has 
been  suggested  that  a  SMITE  implementation  is  secure  if  its  specification  is  Terry- 
Wiseman  secure  ITerTy89),  and  its  safety-refined  implementation  is  isomorphic  to  the 
specification.  Given  that  implementations  are  protected  by  an  information  hiding 
mechanism  [Wtseman90],  it  would  seem  that  isomorphic  implementations  would  be  too 
restrictive  -  they  are  certainly  artificially  complex. 

The  requisite  mathematical  notions  are  recalled  in  section  2  A  discussion  of  secure 
refinement  in  section  3  motivates  the  choice  of  "behavioural  equivalence*  as  a  useful 
definition  The  definition  is  investigated  in  terms  of  model-oriented  Z  specifications 
ISpivey89)  in  section  4,  and  a  proof  obligation  for  behavioural  equivalence  is  posited, 
behavioural  equivalence  is  difficult  to  characterise  for  non-deterministic  systems, 
and  the  limitations  are  sketched  In  section  5,  behavioural  equivalence  is  formally 
defined  as  a  means  to  proving  the  validity  of  the  proof  obligation 


2  Signatures,  Algebras  and  Morphisms 

Z  specifications  describe  algebras,  but  the  algebraic  concepts  underlying  notions  of 
correctness  are  best  understood  in  the  context  of  algebraic  specifications  The  main 
definitions  are  recalled  in  this  section. 

Informally,  a  signature  Xis  a  set  of  sort  names,  together  with  a  set  of  operator  names 
each  of  which  has  a  declared  syntactic  structure  (cf.  type)  formed  from  x  and  For 
example,  the  signature  of  a  cut-down  algebra  of  number  sets,  called  Bunch ,  might  be 
,  written. 

{  sorts  bunch,  bool,  nat 

1  opns  empty  :  bunch 

*  *  insert:  bunch  x  nat  — *  bunch 

ism :  bunch  x  nat  — *  bool 

'  A  L-Algebra  is  a  signature,  L,  together  with  an  assignment  mapping  each  sort  to  a  set  of 

values,  called  its  carrier ,  and  each  operator  to  a  total  function,  called  an  operation 1 


*In  practice,  the  operation*  would  not  be  defined  directly  in  thi*  manner  Rather,  the  operations 
would  he  defined  indirectly  by  equations  on  the  operators  The  a’gebra  which  assigns  total  functions 
and  earner  *et*  to  each  operator  and  tort  u  then  chosen  from  the  set  of  al)  algebras  satisfying  the 
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The  carrier  of  sort  s  in  algebra  A  is  written  I  At  I .  For  example,  let  the  carriers  of  a 
Bunch-algebra  A  be  the  familiar  mathematical  sets  of  numbers  and  binary  logic 
values,  thus- 


1  Afcooch  I  =  ft! 

I  Aiool  I  =  (0,1) 

lA^l  =  N 

The  operations  are  the  familiar  ones  from  set  theory. 

0 

Aia«rtfl>,n)  fi  bu{n} 

A,tfn(bj.n>  a  if  n  c  b,  0  otherwise 

This  readily  accords  with  our  expectations,  and  could  be  offered  as  a  specification  of  a 
system  of  bunches  The  Bunch-algebra  B,  on  the  other  hand,  chooses  unordered 
sequences  to  represent  bunch,  thus 

I  Bfcjndi  I  =  seqN 

nw  =  (0,1) 

1B„,I  =  H 

with  the  operations 

B«,pty  <> 

fi  b  n  > 

BjunfB.n)  fi  if  n  <  ran  b,  0  otherwise 

Now  if  A  is  the  specification,  is  B  a  correct  implementation7  This  is  precisely  the  safety 
refinement  problem  B  is  a  safety  refinement  of  A  if  B  is  homomorphic  to  A  (Jones86] 

A  homomorphism  between  two  E-algebras  is  a  total  surjection  between  the  carrier  sets  of 
the  two  algebras  which  preserves  the  semantics  of  the  operations  To  show  that  an 
algebra  B  is  homomorphic  to  algebra  A  entails 

1.  constructing  an  interpretation  of  the  earners  of  B  (wrt  the  earners  of  A) 
i  e.  a  total  surjection  from  each  carrier  set  of  B  to  its  corresponding 
carrier  set  of  A  (cf  retrieve  functions  (Jone$86}), 

2  for  each  operation,  and  each  input’  proving  that  B's  definition  interprets 
toA's  definition 

In  the  example,  suitable  interpretations  of  the  carriers  of  B  m  terms  of  the  carriers  of  A 
is 


ibunch  =  x  b  seq  N  •  ran  b 
ibool  =  {1*-*  1, 0«—*  0) 

inat  =  idN 

To  prove  the  insert  operation,  for  example,  we  must  show  for  any  bunch  b  and  any 


equations,  depending  on  how  the  equations  are  interpreted  (e  g  'term  algebra  |Goguen78])  The 
algebras  are  explicitly  defined  in  this  section  purely  to  motivate  the  algebraic  notions  underlying 
refinement 
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number  n. 


ibunch(B10tm(b,n))  =  A,otm(ibunch(b),  mat(n)) 

which  is  expanded  successively  using  the  definitions  of  Binttrl  and  A^tn,  then  ibunch 
and  inat,  as  follows: 

=>  ibunchfb  n  >)  =  (ibunch  b)u(  mat  n) 

=>  ran  (b  ~<  n  > )  =  (ran  b) u { n ) 

which  is  a  property  of  the  range  of  a  catenated  sequence.  It  is  easy  to  show  that  the  other 
operations  preserve  the  interpretation,  and  thus  B  is  homomorphic  to  A 

Two  algebras  are  isomorphic  if  they  are  homomorphic  as  above,  and  the  interpretation 
is  a  total  bisection.  In  the  example,  the  only  algebra  (with  1  B^unth  I  =  seq  IV  )  which  fits 
this  property  uses  ordered  injective  sequences  For  example,  the  set  {1,3,5}  must  be 
represented  by  the  sequence  <J,3,5>,  and  cannot  be  represented  by  <1,5, 3>  for  instance. 
Also  excluded  are  representations  which  include  junk'  -eg  <1,3,3,3,5>  A  more 
telling  example  involving  junk  is  a  sequence  and  pointer,  for  instance: 

<1,3,5,9> 

T 

The  fourth  element  of  this  sequence  is  junk,  but  its  presence  renders  the  representation 
non-isomorphic.  The  representation  could  be  made  isomorphic  by  insisting  that  the 
number  of  junk  elements  is  constant,  and  that  all  junk  is  the  same  value  (e  g  0)  Such 
a  compromise  can  be  a  nuisance  when  scaled  up  (e  g.  field  padding  in  database) 


3  Secure  Implementations 

Algebra  B  above  is  not  isomorphic  to  A,  because  the  ordering  and  duplication  of 
elements  within  a  sequence  is  not  unique  One  might  argue  that  B  is  an  insecure 
implementation  of  A,  given  the  knowledge  that  elements  are  catenated  successively  by 
mserf  However,  by  hiding  the  carrier  set  of  bunch  from  every  user  of  the  algebra  B, 
any  information  subtly  encoded  within  the  stored  sequence  cannot  be  decoded  * 
information  can  be  transmitted,  but  never  received*.  This  is  the  purpose  of  data  hiding 
in  SMITE.  Under  this  interpretation,  we  have  shown  a  non-isomorphic,  secure 
implementation 

Other  non-isomorphic  implementations  might  not  be  secure,  however  For  example, 
suppose  the  signature  in  the  above  example  had  another  sort,  called  display,  and  an 
operation 


show  •  bunch  — •  display 

which  shows  the  user  which  elements  are  in  the  bunch  Suppose  the  algebra  A  defines 
the  new  carrier  and  operation  as 

I  AdupUy  I  =  M 
A»how(h)  ®  b 

but  suppose  B  defines  it  as 


*Other  than  by  observing  modulations  in  response  time 
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I  B&ipi.y  I  s  seqH 
B*how(b)  2  b 

The  problem  is  that  the  user  of  B  can  now  observe  modulat.on$  m  the  use  of  the  bunch  by 
performing  Skow.  B  is  not  isomorphic  to  A  Clearly,  ‘hiding*  display  would  contradict 
its  purpose,  so  we  must  reject  B  as  an  insecure  implementation  of  A.  Even  if  the  display 
was  always  presented  in  the  same  order,  duplicate  elements  would  constitute  a 
signalling  medium  Therefore,  suppose  algebra  C  is  the  same  as  B  except  that  it  does 
not  store  duplicate  elements  (the  stored  sequences  are  injective),  and  C,Ao«-  displays  the 
stored  sequence  in  a  fixed  order,  thus: 

I  Crunch  I  =  iseqN 

1  C&jpUy  I  =  iseqN 

C*how(b)  2  order b 

where  the  function  order  re-orders  any  sequence  of  numbers  in  non-decreasing  order 
(eg  order  <3,5,1>  «=  <1,3, 5>)  C  is  a  secure  implementation,  but  it  is  still  not 
isomorphic  to  A1,  because  any  set  of  numbers  corresponds  to  possibly  many  distinct  re¬ 
orderings  of  the  stored  sequence 

What  then  is  a  secure  implementation7  The  answer  is  one  which  behaves  the  same  as 
the  specification  with  respect  to  the  non  hidden  sorts  Hence  Behavioural  Equivalence 
(Sannella83)  The  following  definition  of  b  e  is  given  in  [Sannella84] 

"Two  algebras  are  behaviourally  equivalent  with  respect 
to  a  set  of  observable  sorts  if  and  only  if  they  give 
corresponding  answers  to  every  computation  taking 
inputs  of  observable  sorts  and  yielding  a  result  of 
observable  sort " 

In  the  equational  specifications  expounded  in  (Sannella83,84,  Goguen78],  this  property 
C3n  be  shown  by  checking  the  definitions  of  observable  operations  against  the 
equations  on  observable  sorts  Their  only  problem  is  finding  an  algebra  which 
corresponds  to  a  sufficiently  loose  interpretation  of  the  equations  (e  g  ’initial'  algebra 
(Goguen78)) 

Z  specifications  are  usually  not  described  exclusively  by  equations  Instead  we  define 
pairs  of  models,  one  of  which  is  the  specification,  the  other  the  implementation,  and  '  ^e 
don’t  have  equations  to  test  for  behavioural  equivalence  Also,  Z  specifications  are 
non-determmistic  in  general,  so  they  describe  sets  of  algebras  We  need  to  show  that 
representative  algebras  of  each  specification  are  behaviourally  equivalent,  without 
reference  to  any  equations  This  might  be  achieved  by  showing  a  one-to-one 
correspondence  between  output  variables  in  operation  schemas  This  is  investigated 
informally  m  the  next  section 


4  Behavioural  Equivalence  in  Z 

4.1  Z  Specifications  and  Refinements 

The  Bunch  example  from  above  is  re  specified  in  Z  Then  a  p-oof  obligation  for 
behavioural  equivalence  is  posited  and  investigated 

Tne  earner  set  of  the  bunch  in  algebra  A  above  is  represented  by  a  state  schema  in  Z,  as 
^though  the  interpretation  for  display  is  byeetive 
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follows: 


Bunch  fi  lb  PM ) 

The  operations  are  also  defined  using  schemas  in  the  usual  manner,  one  schema  per 
operator  of  Bunch. 

Empty  ft  l  Bunch'  I  b’  =  0  ) 

Insert  ft  ( Bunch;  Bunch*; i? : M  I  b’  =  bo  (i?)  J 
display  ==  PM 

Show  ft  (  Bunch,  d’  display  I  d!  =  b  ) 

The  (insecure)  bunch  representation  (algebra  B  above)  is  represented  by  the  following 
schemas: 


BanchL  ft  {b*:seqM] 

Emptyv  ft  ( Bunch  (  I  b{  e  <>  ) 

Insert  ft  l  Buncht;  Bunchy,  1? .  M  I  bv  =  b; ' 
displayi  es  seqM 

Showt  a  (  Bunchy  d|*  displayt  I  dt’  =  ) 


<i’>  1 


The  relationship  between  the  states  of  these  two  specifications  is  described  by  the 
following  abstraction  schema: 


Abs  s  (  Bunch;  Buncht  I  b  n  ran  \\ ) 

This  schema  corresponds  to  the  homomorphic  mapping  ibunch  above 

The  (secure)  implementation  algebra  C,  differs  in  the  treatment  of  injective  sequences 
in  the  state  and  the  ordering  of  the  display 


Bunch  ft  (bi:iseqM) 

Insertli  ®  (  Bunch*.  Bunchy,  i?  :  M  I 

i7  <  ran  b*  /s  b*’  =  b*  "■*  <i?>  v 
i7 1  ran  b*  *  b*' r  b*  ) 

display  1*  ==  ( s  iseq  M  I  s  c  ran  order ) 

Showl*  ft  (  Bunchv;  d^'display*  I  <V  =  order  b*  ) 

In  the  example,  neither  of  the  implementations  is  isomorphic,  because  many  distinct 
re-orderings  of  the  sequences  correspond  to  the  same  set  of  numbers  (many-to  one)  In 
order  to  make  the  last  implementation  isomorphic,  we  would  need  to  store  the  sequence 
in  sorted  order,  rather  than  ensuring  that  only  ordered  sequences  are  output  This 
seems  convenient  enough  in  this  simple  example,  but  it  might  not  be  so  convenient  in  a 
more  complex  system  On  the  other  hand,  some  systems  can  only  be  implemented 
efficiently  with  unique  stored  representations.  The  point  is  that  the  implementer 
should  be  free  to  choose  the  most  convenient  representation,  without  unnecessary 
algebraic  constraints 

This  leads  us  to  consider  a  weaker  notion  of  secure  refinement,  which  is  independent 
of  the  algebraic  relationship  between  specifications  (morphisms)  A  refinement  is 
secure  if  it  is  correct,  and  it  does  not  introduce  new  observable  behaviours.  Therefore, 
we  only  need  to  check  that  corresponding  operations  behave  equivalently  up  to  their 
outputs 
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4.2  Proving  Behavioural  Equivalence 


The  notion  of  ‘behavioural  equivalence'  has  been  proposed  for  some  years  as  a 
semantics  for  abstract  data  types  [Sannella84),  where  a  data  type  description 
encapsulates  its  private  state  within  a  fixed  set  of  operations.  The  operations  are 
permitted  to  manipulate  the  state,  but  otherwise,  the  operations  must  be  used  to  effect  the 
state  indirectly.  The  operations  make  observations  on  the  state  by  proxy,  but  cast  those 
observations  in  terms  of  other,  user-visible  data  types  Once  an  abstract  data  type  has 
been  specified,  it  does  not  matter  how  the  implementation  works  internally,  as  long  as 
it  offers  the  same  observable  behaviour  promised  by  the  specification. 

The  attraction  of  behavioural  equivalence  in  the  interpretation  of  abstract  data  types  is 
that  it  more  closely  reflects  the  "black  box’  view  of  an  abstract  data  type.  Morphisms,  on 
the  other  hand,  deal  with  the  internal  structure  of  the  data  types  -  more  akin  to  a  'white 
box'  view  The  data  hiding  mechanism  in  SMITE  is  based  on  the  black  box  approach. 
Black-box  interpretation  is  a  weaker  notion  of 'correctness'  in  the  following  sense,  for 
any  algebra,  the  set  of  behaviourally  equivalent  algebras  is  larger  that  the  set  of 
'morphous  algebras  In  software  engineering  terms,  the  implementer  is  less 
constrained.  The  treatment  of  behavioural  equivalence  in  abstract  data  types  has 
focussed  on  algebraic  specifications,  but  Z  specifications  are  model-based  A  definition 
of  behavioural  equivalence  in  terms  of  Z  specifications  follows 

In  general,  two  systems  are  'behaviourally  equivalent'  if  there  is  a  one-to-one 
correspondence  between  the  results  of  'executing'  corresponding  sequences  of 
operations  Inductively,  this  is  the  case  if  corresponding  operations  have  a  one-to  one 
(actually  ’bijective’)  output  correspondence  Consider  state  spaces  5  and  St,  related  by 
the  abstraction  Abs ,  along  with  the  operation  OP  and  its  implementation  OPu  as 
follows. 

Abs  ft  (  S,  I ...  1 

OP  ft  (  S;  S'.  iM,  o’  0  I  ) 

OP4  ft  [  S4;  Sl';  i’  I,  o4*  04  I  ..  1 

(Assume  that  inputs  are  not  refined) 

For  corresponding  operations  OP  and  OP4,  the  output  correspondence  is  the  following 
relation 


out  =*■  { OP,  OP4j  Abs;  Abs'  -  (o^o’)) 

We  must  show  that  the  output  correspondence  is  a  total  byection1,  thus 
h  out*  (\>-*0 

The  obvious  way  of  proving  this  property  is  to  construct  the  output  correspondence 
relation  from  the  operation  definitions  and  the  abstraction,  and  show  it  is  byective 
Indeed,  such  an  output  correspondence  relation  is  required  m  order  to  prove  the 
'correctness'  of  the  operation2  In  the  case  of  the  Show  operation  m  the  first  (insecure) 
refinement  above,  the  relationship  is  as  follows 

{ Show,  Show4;  Abs,  Abs’  •  (0|*,  o’) } 


JIn  practice,  the  output  correspondence  will  often  be  an  identity  function 
2A3though  the  published  refinement  methods  usually  ignore  this 


which  can  easily  be  cccsstrucud  fna  the  Scar  *nd  Scccj  cperacxcs  where  Ojf  *  erdrr 
6*.  and  thus: 

Cyseqftfcffi  -  Cb-^MJ 

but  the  abs^aetkn  AS*  equates  6  =  rm:fc|,  so  the  cct?ctcsrT«pc=de»*  redacts  ta 
Gyseq K bdrlf  -  (2>„raabs)} 


which,  although  functional,  is  dearly  net  fcrjecfire.  since  scene  distinct  sequences  bare 
the  same  range  (eu&  run  <2J3>  *  rcc  <3,2>X  The  refinement  is  therefore  set  secure. 
The  correspondence  for  *!  *  second  (secure)  refinement  is 

ahsoutl  =  (Show;Shcwlt:Abs;Ahs'  -  (c*!.  oli ) 

which,  since  o*/  =  order  6*.  and  o!  -  b  in  the  definitions  of  Shoo-  and  Shari  |,  is  as 
follows: 


{b*=seq  ft  kFft  •  (crderb*.b)} 

but  again  the  abstraction  reduces  the  output  correspondence  to 

(b*dseq  Tt  b:r*<  -  (order  bl,  ran  b*) } 
i.e. 

x  ^display  1*  -  rani* 

which  is  a  total  bijection  because  each  set  of  numbers  has  a  unique  order.  The  second 
refinement,  with  its  non-duplicate,  unordered  sequence  is  therefore  secure. 

■13  Non-determinism 

Behavioural  equivalence  is  only  valid  for  deterministic  specifications1,  where  the 
outputs  of  operations  are  uniquely  determined.  Otherwise,  non-determinism  renders 
the  output  correspondence  non-functional  For  example,  suppose  the  bunch 
specification  provided  an  operation  to  select  an  arbitrary  number,  thus 

Select  ft  (  Bunch;  n!H 1  b* 0  ~  n1 1  b  ] 

The  number  of  possible  outcomes  from  Select  is  *b.  Suppose  its  implementation  always 
(i  e  deterministically)  selects  the  minimum  number,  i  e. 

Select*  ft  [  Bunch*.  n*!f(l  b**0  ~  n*!  =  1  ■adtorderb*)  ) 

Now  the  output  correspondence  is  a?  follows 

( biiseqj  It  nTan  b*  •  (head(order  b*).  n) ) 

which  is  a  (one-to-many)  relation  since,  for  example  if  6j*  <7,2>,  the  correspondence 
is 

(2.-.  7.2-2) 


’The  author  is  grateful  to  Professor  C  B  Jones  for  pointing  this  out 


9 


the  cc^ci  escrwycndecr »  a  t=*=y- 


to-=xry  rtbtws. 

Ahhccya  the  prs&ka  is  nad  by  sc s-j«ffr.aaa:  ^tgSa^si.  fc  b  tbe  systems 
whada  seat  be  &tUr=~z~vzir.  g  tt-«r  «ydi  the  sye^rrtiaa  say  be  Tease",  presided 
cafr  cf  6t  t^CTiaa  are  toadtd.  Oy&fsiaacf 

secure  rt£=eu*ui  is  bwd  co  tf  6f  s^Tnlya.  net  a  sj^ta  2s  ici,  m  we 

are  frreedi  b  g$$s=e  th:  tie  spedfkxika  is  ibtif  dti«=2Bi&  (wkh  respect  to 
cctpctsl  This  rests  2  further  peref  ci^ziira  fee  tie  epentkes. 

Use  njak^a  to  drtercsasstsr  ^esfKeos$  does  net  prdsde  Tccsezess'  a  the 
deftukko  cf  crocks  ISpcreySS].  Fee  exarcple.  cct  selectka  epera^oo  cccSd  cheese  fcs 
raise  n  *  fixed  (Le.  fbartkual)  nrstr,  bat  tie  fczsxt  cf  the  isa  £23  be  left 
ca^cSci  fea: 


6x«:P/i-K 

Select  •  (  B=nch;nlfi  I  b/Q /vid=  dxeseb  1 


Tie  above  inpItrtsbUKJ  ^erifjatba,  Select^  is  caly  correct  if  the  choke  cf  the 
ciansa  stored  number  is  in  ese  bese  correspondence  with  chocs*,  end  it  is 
KssitKt  wti  cheat. 

The  specification  cf  state  variables  can  be  non-deterministic.  as  long  as  the  non- 
dfbrsinita  is  resolved  by  the  specification  cf  output  variables.  In  an  abstract 
specification.  Le.  without  redundancy  etc.,  noa-determinism  in  the  state  is  Kkely  to 
give  rise  to  non-determinism  in  the  outputs.  Implementation  specifications,  on  the 
other  hand,  introduce  genuine  redundancy,  so  non-deterministic  state 
transformations  are  store  likely  to  be  concealed-  In  the  bunch  example,  the  secure 
implementation  determined  the  order  of  the  bunch  sequence  from  the  order  of 
insertions.  This  was  sorted  for  output  However,  the  implementation  specification  for 
Insert  could  have  made  a  non-deterministic  choice  for  the  position  of  the  new  number 
in  the  state,  thus: 

Insert lt  •  [  Bunchy  Bunch;';  i? :  H  I 

i?<ranbl^ranbj*  =  ranblu(i,i  ~ 
i?«ranbi~bi'  =  bi  ) 

This  even  allows  existing  numbers  to  be  re-ordered  The  important  point  is  that  the 
system  never  outputs  any  clues  concerning  the  stored  order.  Notwithstanding  non¬ 
determinism  in  the  specification  of  state  transformations,  it  will  often  be  more 
convenient  and  efficient  to  factor  output  filtering  to  the  state  itself.  In  terms  of  the 
example,  the  bunch  would  be  stored  in  number  order.  This  makes  the  implementation 
isomorphic  to  the  specification,  purely  as  a  matter  cf  convenience.  In  practice,  other 
redundant  information  in  the  state  would  make  it  quite  difficult  to  force 
representations  to  be  one-to-one,  which  is  the  very  reason  we  propose  the  more  relaxed 
notion  cf  behavioural  equivalence. 

The  usual  criteria  for  correctness  of  representations  corresponds  mathematically  to 
homomorphism  Our  definition  of  secure  refinement  uses  the  machinery  of 
homomorphism  in  constructing  a  proof  of  behavioural  equ.valence.  [Nipkow86] 
suggests  a  generalisation  of  homomorphism  called  ‘simulation’  which  accommodates 
non-determinism  in  observalionally  equivalent  specifications  This  could  be  a 
fruitful  line  of  research  for  secure  refinement,  if  the  restriction  to  non-deterministic 
specifications  proves  to  be  impractical 

In  the  next  section,  behavioural  equivalence  is  formally  defined  as  a  means  to 
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crtCiptirj  tic  cf  tit  prof  jJr«  a  th»  kOki 


5  Formal  Treatment 
5-1  Systems 

la  this  section.  Behavioural  Eq=5r22«c*  is  formally  defined,  asd  the  proef  cfeSgatiso 
cf&cpgrogttt^a»it6watobe«S3«gh»?KttotIai&£a&a 

A  s^letr2asitiaa  relation  ca  a  oca-empty  set  cf  states  S,  a  nco-empty  set  cfmpcUJ,  a 
cca-emp«y  set  cf  outputs  0,  aad  a  »ca-empty  set  cf  operation  names  OPS  defines  for 
trh  operation.  inpd,  and  state,  possible  state,  output  outcomes.  Let  the  set  ef  all 
operations  OPS.  the  set  cf  all  c;  pets  /.  tlx  set  cf  all  possible  states  S  and  outputs  O  be 
fixed. 


10PS.IS.0) 

The  set  of  all  state  transition  relations  is  defined  as  fella**: 

TH  =  (OPS  *I*S)— »(S*0) 

A  system  is  modelled  by  a  non-empty  set  cf  states  2,  a  non-empty  set  of  outputs  A,  an 
initial  state  c.  and  a  state  transition  relation  nest  cn  these  sets  The  set  of  all  systems  is 
defined  as  follows: 

I - SyKCT - . 

Z:t£ 

Q:  P,0 

o:S 

next  TH 


ac£ 

next*  (OPSxIxS~CxA 
dom  next  =  (OPS  x  I  x  D 


The  initial  state  is  a  state  of  the  system,  the  state  transition  relation  is  restricted  to  the 
states  and  outputs  of  the  system,  and  the  transition  relation  is  total. 

5.2  Behaviour 

A  system  scenario,  is  a  sequence  of  operations  invoiced  with  their  inputs,  and  the 
corresponding  output  "behaviour"  is  a  sequence  of  states  and  outputs  The  set  of  all 
possible  input  scenarios  is  called  Scene,  and  the  set  of  all  possible  output  behaviours  is 
called  Befiavzour. 

Scene  ==  seq  (OPS  x  I) 

Behaviour  ==  seq  (S  x  O) 

The  behaviour  of  a  system  with  respect  to  a  given  initial  state  is  described  by  the 
following  iterator,  which  determine^  for  any  transition  relation  tr,  a  function  of  any 
starting  state  st  -  giving  the  relationship  between  wenanos  and  possible  behaviours. 
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_g-:7S—  CS  — *  (Setae--  Bthiisr)) 


ytrSE;s£S  - 

(tr»  si  )  IJoD  =  (o)  * 

{Vj5ose  l**o» 

(trS  sOCfsD  =  {pi=!m  -  <p>'~(trt  (fstp)(tlsi> 
cf-er 

aim  =  fciZ&Cbd  s).  snd&d  s).  siXD 

513  Ontput-DefenninisticSvstems 

We  «ly  ccsKder  deterministic  systems.  it  any  scenario  give*  rise  to  a  unique  output 
behaviour.  The  cctput  behaviccr  corresponding  to  a  behaviour  sequence  b£ekesiozr  is 
blind.  This  observation  is  generalised  for  the  iterated  state  transition  relation  by  the 
special  operator  ssnd,  such  that  r.ez  t  t;sizd  a  is  a  relation  between  input  scenarios 
and  output  behaviours. 

f - EA3.C1 

Sind :  (A— stqfB.Cj)  —  (A— 


ssnd  =  (xit(A~seq{BxC))  -  rjsnds) 
xxhar 

sndsss(xsseq>BxC)  -  sjsr.d) 


The  set  of  output  deterministic'  s>  stems,  Dsystem,  is  defined  as  the  set  of  systems  with 
functional  input-output  behaviours 


- Dsystem 

System 


J  next^jssnd  « (I  — ♦  (Scene—*  seq  ft)) 

1 _ . 

This  property  enables  us  to  write  the  term  near  t  fjssnd  as  to  refer  unambiguously  to  the 
output  behaviour  of  a  deterministic  system  started  in  its  initial  state  a,  executing  the 
input  scenario  s 

Lemma  LI.  An  output  deterministic  state  transition  function,  iterated  on  an  empty 
scenario,  yields  an  empty  output  behaviour 

Dsystem  *•  (next&;s$nd)  ao  =o 


5.4  Behavioural  Equivalence 

Two  systems,  A  and  B,  with  the  same  input  set  /  and  operation  names  OPS  are 
behaviourally  equivalent,  written  A  be  B,  if  and  only  if  both  systems  produce 
equivalent  behaviours  for  any  conceivable  scenario  s,  up  to  a  byective  interpretation  of 
outputs  interp 
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Jbe. :  Dsjstem  —  Dsysiem 


Y*Jb cDsystta  « 
abeb«*> 


(a«~*b)«  {Dsystem^Dsystem,  1 

Gir-'-trp-AOPS  xQj)>—  Q*  -  V  iSctze  - 
(next*5;s«sd)  c*s  =  (s;fsix  ((ncct*5;$»d)  c,  s>;bierp))} 


where  the  cperatcr  x  combines  two  equal  lenph  sequences  in  a  pcmtwise  fashion.  thus: 

-  IA.E] - 

-XS  («q(A)  *  seq(B))  —  seq(AxB) 

_j.=  xa.seq(Ahbseq{B)  I  #a=*b  -  xi:dom  a  •  (a  i, b i) 

1 _ , 

Lemma  L2:  The  pointwise  combination  of  the  empty  sequence  is the  empty  sequence: 

►  oxo=  o 

&5  Proof  Obligations 

The  set  of  all  possible  outputs  from  a  given  operation  op.  written  o  op  fr  is  defined  as 
follows' 

|  o:OPS  — TH  —  FO 


I  o=  xopOPS  •  Mr.TR  •  ran(ran(([op)xIxS)<Jtr) 

Proposition  Two  output  deterministic  systems,  A  and  B,  are  (maybe)  behaviourally 
equivalent  with  respect  to  an  abstraction  relation  c6s  if  each  operation  induces  a  total 
bisection  on  the  outputs  of  the  corresponding  state  transition  functions,  thus 

j  ma>bc  (S  *-•  S)  — •  (Dsystem  *-*  Ds>-stem) 


xna>bc=  xabs  S*-*S  • 

{ Dsystem*.  DsyslemB  I 
abs  c  £b  ♦-*  Ia^n  (ob  ga)  c  abs  ~ 

VopOPS  ■ 

outabs  c  (o  op  nextfi)  >*  (o  op  nextA> 
when 

outabs==  {iI,ca^;o8Jb1  ob«-»oa«  abs  • 

(nextAJsnd  (op,  i,  OjO.  nextB>snd  (op,  *,  eg))) 

This  is  not  an  alternative  definition  of  behavioural  equivalence,  but  is  a  sufficient 
condition  on  the  operations  of  a  s>slem  to  guarantee  it 
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5S  Validity 


Btfoeant  can  be  summarised  by  the  following  collective  proof  obligations:  the 
specifications  must  be  output  deterministic ;  One  specification  most  ssfety-refir.c  the 
ether  -  this  process  yields  an  abstraction  relation  and  a  proof  that  all  operations  are 
mono  tonic  with  respect  to  this;  and  finally  a  proof  that  corresponding  operations  from 
the  two  specifications  each  have  a  bijective  output  correspondence.  These  proof 
obligations  are  specified  in  the  following  schema: 

- Proef_cbl:g - - 

cbsS  *-»S 

Dsyslesv,  Dsysiem, 


ahscEg*-*!* 

(C3-»oa)«^js 

VopOPS;  iJ;oA'^»;<vI^  I  cb»-*ca<  abs  - 

absCnextB;fstl((cp.ifcB)J3  £  nextA;fsU{(op,i^A)l> 

(6DsystemA.  GDsystema)  c  (maybe  abs) 


The  validity  cf  maybe  as  a  proof  obligation  is  stated  as  follows. 

Troof.oblig 

I- 

GDsystem*  be  GDsystem# 


5.7  Validity  Proof  Outline 

An  outline  proof  of  validity  for  the  proof  obligation  follows  Examining  the  definition 
cf  be,  we  show  for  every  pair  of  deterministic  systems,  the  existence  of  a  bijective 
interpretation  function  which  translates  all  outputs  from  one  system  to  the 
corresponding  outputs  of  the  other  There  are  four  main  steps: 

1.  Generalisation  prove  validity  for  any  two  systems  A  and  B 

2  Existence  posit  an  assignment  for  interp 

3  Bijectivity:  prove  that  interp  is  bijective 

4  Induction  prove  that  interp  translates  all  output  sequences  from  B  as 
corresponding  output  sequences  from  A. 

Step  1  simply  involves  dropping  the  universal  quantifier,  reducing  the  argument  to 
any  two  systems  DsystemA  and  Dsystem,  Step  2  constructs  the  following  assignment 
for  interp,  based  on  absout  in  the  definition  of  maybe- 

interp  =  U  { op  OPS  • 

(iI;oA^:oBTel  C£  oA  c  abs  . 

(op,  nextxjsnd  (op,  i,  oA».  nextB;snd  (op,  i,  oB)  11 

Step  3  shows  that  interp  is  bijective,  i  e 

interp*  (OPS  xf^)*-*  O* 
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The  antecedent  cf  the  proof  obligation  establishes  for  each  operation  op  that  the  function 

cbzout,  it. 

[  LI;  <7*1*:  I  eg  —  C\  c  abs  •  <ne3rtA*,snd  (op,  i,  a*),  nextBjsnd  (op.  i.  cb)  ) 

is  a  total  bijecticn  on  the  inputs  and  outputs  of  the  corresponding  operation.  Our 
assignment  to  interp  is  the  union  of  all  cf  these  bisections,  each  labelled  with  its  op. 
This  labelling  partitions  the  hijections,  so  the  union  is  also  bijective.  The  union  is 
total,  since  each  component  bisection  is  total,  and  there  is  one  component  for  every 
operation. 

The  main  proof  step  (4)  is  requires  us  to  pros  e  that  inltrp  actually  translates  the  outputs 
of  system  B  to  the  outputs  of  system  A,  i.e. 

V  s:Scene  *  (next**;ssnd)  aA  s= (»;f$tx  ((next^jssnc)  aBs);interp) 

which  is  prosen  by  induction  on  the  sequence  s. 

The  base  of  the  induction,  with  **<>  is  as  follows: 

(nextAifc;ssnd)  aA  <>  =  (ojfst  x  ((next*£$ssnd)  cs  o)$ir»terp) 

Applying  lemma  LI  to  the  left  and  right  of  the  base  ease,  reduces  it  as  follows 

o  =  (o;fstx  o);interp 

which  is  discharged  by  lemma  L2,  since  the  composition  of  an  empty  sequence  with  a 
function  is  the  empty  sequence 

The  induction  step  is  as  follows  Assuming  the  properly  holds  for  a  non-empty 
scenario  t,  1  e 

(nextA4;ssnd)  aAt  =  (tjfstx  ((nextc&jssnd)  aBt)$wt*rp) 

prove  it  holds  for  the  scenario  t  extended  with  the  operation  op  and  input  i ,  1  e 
s* t  '~'<(op,i)>,  as  follows. 

(nextA*jssnd)  ctA(t~<(op,i)>)  = 

((t~<(op,i)>);fstx  ((nextj.*;ssnd)  a*(t~<(op,i)>))Jinterp) 

This  is  the  case  if  the  output  behaviours  of  A  and  B  correspond  ovt'  the  initial  scenario 
/,  as  well  as  the  additional  operation,  op  with  input)  (which  amounts  to  distributing  the 
iterated  transition  functions  over  sequence  catenation,  and  further  distributing  tnterp 
through  sequence  catenation).  The  corresponding  subgoals  are 

(1)  (nextA#Jssnd)  aA  t  =  (tjfst  x  <(next*fc;ssnd)  a*  t);mterp 

(ri)  V  oA  $ndflastfnextA*  aA  tB;  ai'sndflastfnext**  Oa  tB  • 

nextA;snd  (op,i,  oA )  =  inteKop,  next*;snd  (op,i,  aB )) 

The  first  subgoal  0)  is  the  induction  hypothesis  The  second  subgoal  (n)  requires  u>  to 
show  for  the  extra  input,  that  the  interpreted  output  from  B  is  identical  to  the  output  from 
A,  for  each  possible  state  oA  after  executing  A  over  t,  and  each  corresponding  state  oB 
after  executing  B  over  t  The  proof  step  is  valid  because  the  systems  are  deterministic, 
and  the  states  oA  and  ot  are  guaranteed  to  be  ’equivalent’  up  to  abs  (safety  refinement) 
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In  other  words,  both  systems  make  the  extra  state-transition  from  the  same  starting 
point.  The  proof  of  subgoal  (ii)  follows  by  generalisation  on  aA  2nd  o>,  and  expanding 
the  definition  of  inter 

This  outline  proof  has  been  mechanically  checked  using  the  B-tool  IBP1].  The  only 
additional  simplification  made  was  to  exclude  "type-checking”  from  the  proof 
lemmas.  It  would  be  valuable  to  fully  elaborate  the  formal  proof,  and  to  remove 
simplifying  assumptions  such  as  unique  initial  states.  Also,  the  relationship  with 
other  refinement  activities  should  be  investigated,  perhaps  integrating  the  process  of 
constructing  output  abstractions  into  the  safety  refinement  process 


6  Conclusions 

As  the  specification  of  a  multi-level  secure  system  is  refined,  extraneous  behaviours 
introduce  signalling  channels  Isomorphic  refinements  do  not  expose  any  more 
signalling  channels  than  are  already  present  in  the  specification,  but  our  experience 
shows  that  eliminating  implementation  tricks  such  as  redundancy  and  unreachable 
states,  increases  the  mathematical  complexity  of  refinement.  Using  a  looser  notion  of 
secure  refinement  based  on  behavioural  equivalence,  in  concert  with  a  data  hiding 
mechanism,  the  implcmenter  is  afforded  greater  freedom  without  any  loss  of 
information  flow  security  We  have  shown  that  it  is  eas>  to  prove  behavioural 
equivalence  of  deterministic  systems  For  non-determmistic  systems,  it  might  be 
possible  to  define  an  analogous  notion  based  on  'simulation'. 

We  have  attempted  to  characterise  secure  refinement  as  liberally  as  possible,  and 
proposed  suitable  proof  obligations,  but  as  our  definition  is  independent  of  the  security 
policy,  it  is  slightly  over-cautious,  although  not  as  over-cautious  as  isomorphism 
However,  the  process  of  discharging  the  new  proof  obligation  is  preferable  to  re¬ 
addressing  the  comple>  security  policj  correspondence  at  each  refinement  step 
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